Using and Configuring Features Version 3.4

Using Layer 2 Tunneling (L2TP, PPTP, L2F)

This chapter discusses Layer 2 Tunneling. It consists of the following sections:

"Overview of L2TP"
"L2TP Terms"
"Supported Features"
"Timing Considerations"
"LCP Considerations"
"Configuring Layer 2 Tunneling"

Layer 2 Tunneling (L2T) consists of L2TP, L2F, and PPTP tunneling protocols.

Layer 2 Tunneling Protocol (L2TP) is an IETF standards track protocol for tunneling of PPP across a packet network such as UDP/IP. L2TP is connection oriented.

Layer 2 Forwarding (L2F) and Point to Point Tunneling Protocol (PPTP) are IETF informational protocols for tunneling of PPP across an IP network.

Overview of L2TP

L2TP allows many separate and autonomous protocol domains to share a common access infrastructure including modems, Access Servers, and ISDN routers. L2TP permits the tunneling of the PPP link layer, for example, HDLC and asynchronous HDLC. Using these tunnels, it is possible to disassociate the location of the contacted dial-up server from the location that provides access to the network.

Traditionally, dial-up network service on the Internet is provided for registered IP addresses only. L2TP defines a new class of virtual dial-up application that allows multiple protocols and unregistered IP addresses on the Internet. This class of network application is useful for supporting privately addressed IP, IPX, and AppleTalk dial-ups through PPP across an existing Internet infrastructure.

The support of these multiprotocol virtual dial-up applications is beneficial to end users, enterprises, and Internet service providers because it allows the sharing of significant investments in access and core infrastructure and allows end users to use local calls when accessing the services.

L2TP also enables the secure use of existing investments in non-IP protocol applications within the existing Internet infrastructure.

Figure 43 shows an example of an L2TP network using ISDN. The network could use any media type between the L2TP Network Access Concentrator (LAC) and the L2TP Network Server (LNS). The example uses the compulsory tunneling model. This chapter also describes the voluntary tunneling model configuration.

Figure 43. Sample L2TP Network

L2TP Terms

The following terms are used when describing L2TP:

Attribute Value Pair (AVP): A uniform method of encoding message types and bodies. This method maximizes the extensibility while permitting interoperability of L2TP.
L2TP Access Concentrator (LAC): A device attached to one or more public service telephone network (PSTN) or ISDN lines capable of handling both PPP operation and the L2TP protocol. The LAC implements the media over which L2TP operates. L2TP passes the traffic to one or more L2TP Network Servers (LNS). L2TP can tunnel any protocol carried by the PPP network.
L2TP Network Server (LNS): An LNS operates on any platform that can be a PPP end station. The LNS handles the server side of the L2TP protocol. Because L2TP relies only on the single media over which L2TP tunnels arrive, the LNS can have only a single LAN or WAN interface, yet is still able to terminate calls arriving from any PPP interfaces supported by an LAC.
Network Access Server (NAS): A device providing temporary, on-demand network access to users. This access is point-to-point using PSTN or ISDN lines.
Session (Call): L2TP creates a session when an end-to-end PPP connection is attempted between a dial user and the LNS. The datagrams for the session are sent over the tunnel between the LAC and LNS. The LNS and LAC maintain the state information for each user attached to an LAC.
Tunnel: A tunnel is defined by an LNS-LAC pair. The tunnel carries PPP datagrams between the LAC and the LNS. A single tunnel can multiplex many sessions. A control connection operating over the same tunnel controls the establishment, release, and maintenance of all sessions and of the tunnel itself.

Supported Features

L2TP runs over UDP/IP and supports the following functions:

Tunneling of single user dial-in clients.
Tunneling of small routers, for example a router with a single static route to set up based on an authenticated user's profile.
Calls can be initiated from the LAC to the LNS (inbound), from the LNS to the LAC (outbound), or by either peer (both). The outbound calls can a fixed (always up) or a demand-based L2 tunneling session.
Multiple calls per tunnel.
Proxy Authentication for PAP, CHAP and MS-CHAP.
Proxy LCP.
LCP restart in the event that Proxy LCP is not used at the LAC.
Tunnel end-point authentication.
Hidden AVP for transmitting a proxy PAP password.
Tunneling using a local rhelm (that is, user@rhelm) lookup table.
Tunneling using the PPP username lookup in the AAA subsystem.

Management of L2TP tunnels using SNMP. See "SNMP Management" in the Protocol Configuration and Monitoring Reference Volume 1.

Note:

Rhelm tunneling requires usernames in name@rhelm format. Tunneling this way requires the software to look through two tables to resolve the destination to which the dial-in user is tunneled. The advantage of using this method of tunneling is that you need only define the rhelm and any usernames that match the rhelm will be tunneled to the same destination.

User-based tunneling is resolved in a single table. It allows you the granularity of tunneling each user to a unique destination.

BRS for an LNS (as a PPP end point).
The ability to use the delete interface command to delete L2TP devices.
The ability to dynamically reconfigure L2TP devices.
Establishment of a sequencing, queueing, retransmission and flow control channel. L2TP also performs sequencing on the data channel.
The ability to fix the L2TP UDP port (1701) so you can establish IP Security filters based on the UDP port.
An L2TP router client. L2TP router client is a "client initiated" (also known as voluntary tunneling) model. This function provides secure, tunneled, multi-protocol Virtual Private Network (VPN) services regardless of service provider topology. This function brings the client and LAC into one physical piece of hardware.
Connection of an inbound call to the appropriate interface based on a remote hostname match. If the remote hostname does not match any of the interfaces configured for hostname matching, the call is completed on an inbound interface that does not use remote hostname matching.
Note: If you have configured multiple net mappings between the same LAC and LNS pair, make sure only one tunnel exists for each mapping.
Automatic IP, IPX, and bridging configuration of inbound nets that do not use remote hostname matching. You must manually configure outbound nets and inbound nets that use remote hostname matching.

Other supported Layer 2 Tunneling protocols include:

L2F-Both NAS and gateway functions are supported.
PPTP-Router client, PAC (PPTP Access Concentrator), and PNS (PPTP Network Server) are supported.

L2F provides interoperable Layer 2 tunneling when connecting to network devices not supporting L2TP.

PPTP provides interoperable Layer 2 tunneling when connecting to network devices not supporting L2TP. Specifically PPTP can be used for VPN services from Microsoft Windows 95 (DUN 1.2 and higher), Windows 98, and Windows NT to IBM routers.

Note:

Both L2F and PPTP are configured in the Layer 2 Tunneling feature.

Timing Considerations

The nature of tunneling PPP packets over routed networks creates some timing issues that you should consider. L2TP assumes that the connection between the LAC and LNS does not have a delay that is long enough to time out the tunneled peers. If the inter-peer latency repeatedly reaches or exceeds that of the PPP state machine's timeout (usually 3 seconds), then connectivity could be hindered. Note that if the latency between the LAC and LNS is this poor, then connectivity in general is so poor that the connection will be unreasonable even if the PPP state machines were kept alive artificially. If both sides possess the capability, then the PPP timeout may be extended to achieving connectivity over a very poor connection.

Besides latency, a bandwidth mismatch between the LAC/LNS pair and LAC/Client pair may cause problems. For instance, if the actual bandwidth between the LAC and LNS is significantly less than the bandwidth of the PPP client, then the LAC may spend significant time trying to send packets to the LNS. On the other hand, if the connection between the LNS and a host on the LNS home network is exceptionally fast compared with the dial-in client, then the LNS may be overburdened trying to send data to the LAC.

LCP Considerations

When using Proxy LCP, the LAC negotiates LCP and PPP continues processing at the LNS. The LAC forwards LCP options to the LNS so that the LNS is aware of what was negotiated. The LNS must remain flexible to the parameters negotiated by the client and LAC. If there are any parameters that are unacceptable to the LNS, then L2TP attempts to renegotiate LCP by sending an LCP Configure Request to the client across the tunnel.

The requirement for the LNS to remain flexible is of particular concern regarding the MRU. On the IBM LNS, the configured MRU is the maximum allowed for Proxy LCP. If the value in the Proxy LCP message from a LAC is greater than the MRU configured on the LNS, then L2TP will attempt to renegotiate LCP with an MRU equal to the configured MRU without changing other LCP options from the LAC.

Configuring Layer 2 Tunneling

To configure L2T:

Access the Layer 2 tunneling feature using the feature command.

Config> feature layer-2-tunneling
Layer-2-Tunneling config>

Enable L2TP, L2F, and PPTP as required.

Layer-2-Tunneling config> enable L2TP

Layer-2-Tunneling config> enable L2F

Layer-2-Tunneling config> enable pptp

Add any L2T networks needed. If this is to be strictly an LAC, L2F NAS, or PPTP PAC, you do not have to add any L2T nets. You should define one L2T net for each simultaneous tunneled PPP connection.

Layer-2-Tunneling Config>ADD L2-NETS
Additional L2 nets:  [0]? 10
Add unnumbered IP addresses for each L2 net? [Yes]: yes
Adding device as interface 31
Defaulting Data-link protocol to PPP
Adding device as interface 32
Defaulting Data-link protocol to PPP
Adding device as interface 33
Defaulting Data-link protocol to PPP
Adding device as interface 34
Defaulting Data-link protocol to PPP
Adding device as interface 35
Defaulting Data-link protocol to PPP
Adding device as interface 36
Defaulting Data-link protocol to PPP
Adding device as interface 37
Defaulting Data-link protocol to PPP
Adding device as interface 38
Defaulting Data-link protocol to PPP
Adding device as interface 39
Defaulting Data-link protocol to PPP
Adding device as interface 40
Defaulting Data-link protocol to PPP

Configure any L2TP, L2F, or PPTP tunnels.

To configure an L2TP tunnel using an AAA local list:

Config>add tunnel-profile
Enter name:  []? lns.org
Tunneling Protocol? (PPTP, L2F, L2TP): L2TP
Enter local hostname: []? lac.org
set shared secret? (Yes, No): [No] Y
Shared secret for tunnel authentication:
Enter again to verify:
Tunnel-Server endpoint address: [0.0.0.0]? 11.0.0.1
 
      PPP user name: lns.org
      Tunnel Server: 11.0.0.1
      Hostname: lac.org
 
 User 'lns.org' has been added
 Config>

You can use the previous example to configure tunnel authorization on the LAC as well as "rhelm" tunneling in the form of "user@lns.org."

You can set tunnel authentication and authorization to be done at a particular RADIUS server. See "Using Authentication, Authorization, and Accounting (AAA) Security" in Using and Configuring Features.

If you are configuring an LNS and tunnel authentication is disabled on both LAC and LNS, then it is not necessary to configure any tunnel profiles.

To tunnel by PPP username on a LAC using either an AAA local list or RADIUS:

 Config>add ppp-user
 Enter name:  []? peter
 Password:
 Enter again to verify:
 Allow inbound access for user? (Yes, No):[Yes]  
 Will 'peter' be tunneled? (Yes, No): [No] Y
 Tunneling Protocol (PPTP, L2F, L2TP): [L2TP] L2TP 
 Enter local hostname: []? lac.org
 Tunnel-Server endpoint address: [0.0.0.0]? 11.0.0.1
 
      PPP user name: peter
      Tunnel Server: 11.0.0.1
      Hostname: lac.org
 
 Is information correct? (Yes, No, Quit): [Yes]
 
 User 'peter' has been added
 Config>

Configure remote hostname matching for the inbound tunnels, if required.
Note that for client dial-in scenarios, this step is typically not necessary. Use this option when a connection should use a specific net.
Assuming that the previous configuration was for net 10:
```
Config> net 10
     L2TP 10> set remote-hostname
     Remote Tunnel Hostname: [] ibm.com
```
Note:
To turn off remote hostname matching, use the following commands:
Config> net 10 L2TP 10> set any-remote-hostname

Configure any L2TP outgoing calls. The following example shows a LAC with IP address 1.1.1.1 and an LNS with IP address 1.1.1.2. The LNS is configured to place a dial-on-demand ISDN call to 5552160 from the LAC.

LNS Configuration:

Config> add tunnel-profile
     Enter name:  []? lac.org
     Tunneling Protocol?  (PPTP, L2F, L2TP): [L2TP]
     Enter local hostname: []? lns.org
     set shared secret? (Yes, No): [No] Y
     Shared secret for tunnel authentication:
     Enter again to verify: 
     Tunnel-Server endpoint address: [0.0.0.0]? 1.1.1.1
 
            Tunnel name: lac.org
               TunnType: L2TP
               Endpoint: 1.1.1.1
               Hostname: lns.org
 
     User 'lac.org' has been added
     Config>
     Config> add dev layer-2-tunneling
     Config> net 10
     L2TP 10> set connection-direction outbound
     L2TP 10> set idle 30
     L2TP 10> set remote-hostname lac.org
     L2TP 10> enable outbound-call-from-lac
        Outbound Call Type (ISDN)? [ISDN]
        Outbound calling address: 5552160
        Outbound calling subaddress:
     L2TP 10>
     L2TP 10> encapsulator
     PPP 10> set name vickie (a)
     L2TP 10>
     L2TP 10> exit
     Config> add ppp-user larry (b)

Notes:

Set authentication name in case the LNS device is authenticated. There are additional prompts that are not shown in this example. For details see, "Configuring PPP Authentication" in the chapter "Using Point-to-Point Protocol Interfaces" in the Nways Multiprotocol Access Services Software User's Guide.
Add users to be authenticated at the LNS. There are additional prompts that are not shown in this example. See Add in the chapter "The CONFIG Process (CONFIG - Talk 6) and Commands" in Nways Multiprotocol Access Services Software User's Guide for a description of the command syntax and options.

LAC Configuration:

Config> add tunnel-profile
     Enter name:  []? lns.org
     Tunneling Protocol?  (PPTP, L2F, L2TP): [L2TP]
     Enter local hostname: []? lac.org
     set shared secret? (Yes, No): [No] Y
     Shared secret for tunnel authentication:
     Enter again to verify: 
     Tunnel-Server endpoint address: [0.0.0.0]? 1.1.1.2
 
            Tunnel name: lns.org
               TunnType: L2TP   
               Endpoint: 1.1.1.1
               Hostname: lac.org
 
     User 'lns.org' has been added
     Config>
     Config> add dev dial-in (a)

Note:

Used to place the physical call.

Configure any L2T router clients. The following example shows an L2TP box-to-box connection using the L2TP router client function. This connection is set in one direction and is demand-based.

Client Configuration:

Config> add tunnel-profile
     Enter name:  []? lns.org
     Tunnel Protocol? (PPTP, L2T, L2TP): [L2TP]
     Enter local hostname: []? client.org
     set shared secret? (Yes, No): [No] Y
     Shared secret for tunnel authentication:
     Enter again to verify:
     Tunnel-Server endpoint address: [0.0.0.0]? 1.1.1.1
 
            Tunnel name: lns.org
               TunnType: L2TP
               Endpoint: 1.1.1.1
               Hostname: client.org
 
     User 'lns.org' has been added
     Config>
     Config> add dev layer-2-tunneling
     Config> net 10
     L2TP 10> set connection-direction outbound
     L2TP 10> set idle 30
     L2TP 10> set remote-hostname lns.org
     L2TP 10> encapsulator
     PPP 10> set name donald  (a)
     PPP 10> exit
     L2TP 10> exit
     Config>

Note:

Set authentication name in case the client device is authenticated. There are additional prompts that are not shown in this example. For details, see "Configuring PPP Authentication" in Nways Multiprotocol Access Services Software User's Guide.

LNS Configuration:

Config> add tunnel-profile
     Enter name:  []? client.org
     Tunneling Protocol? (PPTP, L2F, L2TP): [L2TP] 
     Enter local hostname: []? lns.org
     set shared secret? (Yes, No): [No] Y
     Shared secret for tunnel authentication:
     Enter again to verify:
     Tunnel-Server endpoint address: [0.0.0.0]? 1.1.1.2
 
            Tunnel name: client.org
               TunnType: L2TP
               Endpoint: 1.1.1.2
               Hostname: lns.org
 
     User 'client.org' has been added
     Config>
     Config> add dev layer-2-tunneling
     Config> net 10
     L2TP 10> set connection-direction inbound
     L2TP 10> set remote-hostname client.org
     Config>
     Config> add ppp-user donald (b)
     Config>

Note:

b-- Add users to be authenticated at the LNS. There are additional prompts that are not shown in this example. For details see, "add Config command" in the Nways Multiprotocol Access Services Software User's Guide .

Configure the various feature L2T parameters using the set and enable commands, if desired.
```
Layer-2-Tunneling Config>set ?
Layer-2-Tunneling Config>enable ?
 
```
Configure the PPP parameters for all of the L2 nets which are set for inbound and *any* inbound tunnel hostname using the encapsulator command, if desired.
```
Layer-2-Tunneling Config>encapsulator
PPP-L2TP Config>
```
When you have completed the PPP configuration, enter exit to return to the L2T feature configuration environment.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]